AWSにおける大規模で複雑なニーズを満たすための最適なソリューションを学べる【Advanced Architecting on AWS】を受講してみた

皆さんこんにちは、AWS事業本部オペレーション部の清水です。

AWS Certified Solutions Architect - Professional（SAP） 認定を取得するべく、「Advanced Architecting on AWS」を受講してきました。以下に、学習した内容や参考ブログをご紹介したいと思います。

本コースの受講をお考え中の方へ、お役に立てば幸いです。

AWS認定トレーニングとは？

以下のブログに、弊社AWS認定トレーニング講師の平野のほうで執筆した各トレーニングの詳細が記載されています。

私が今回受講したのは、以下の図の赤枠に入るコースになります。このトレーニングは、AWSが推奨する原則・ベストプラクティスの基本を学べる Architecting on AWSの受講後、SAA資格を取得された後に受講することをお勧めします。実際に私もそのようにしました。

なおこのトレーニングに限らず、モジュールやラボの順番は全て行うと3日間でも時間が足りないため、順不同で進めていくとのことでした。そのため、本ブログでも割愛しているモジュールパートについては、同じように学習した内容の紹介を割愛しております。

事前準備

• AWS認定ソリューションアーキテクトアソシエイトレベルの知識習得
• Architecting on AWSクラスルームトレーニングの受講
• テスト環境等で上記に関連するサービスなどを触っておくこと

１日目

モジュール１：アーキテクチャの確認

FAQ

1. １つのVPCが、複数のリージョンにまたがることができるか？
   1. 誤り
2. インターネットGWを使用せず、プライベートサブネットのインスタンスから、S3バケットにアクセスするには？
   • VPCゲートウェイエンドポイントを使用
     • VPC-ルートテーブル
     • パブリックIP
     • S3・DynamoDB
     • 無料
   • VPCインターフェイスエンドポイントを使用
     • サブネット-ENI
     • プライベートIP
     • DynamoDB以外の対応サービス
     • 時間と転送量で課金

※プライベートIPを使用しなければいけない要件の場合、料金はかかるがインターフェイス タイプのほうを利用する必要がある

ラボ１：Amazon S3 VPCエンドポイントの通信を保護する

1. プライベートサブネットとパブリックサブネットについて、また、それらが Amazon S3 と通信できる理由とできない理由について理解する
2. AWS マネジメントコンソールと AWS CLI を使用して VPC エンドポイントを設定
3. プライベートサブネットで VPC エンドポイントを使って Amazon S3 とやり取りする
4. VPC エンドポイントポリシーを作成してリソースのアクセスを制限

モジュール２：単一アカウントから複数アカウントへ

マルチアカウントアクセスのユースケース

• 完全に環境を分離したければ、アカウントを分ける必要がある
• アカウントを分離すると、ログのセキュリティが強化できる
  • AWS Config - リソースの変更履歴
  • CloudTrail

AWS Organizations

• SCPポリシー
  • 組織内のすべてのアカウントに、利用可能な最大限のアクセス許可を一元管理
  • 組織内のメンバーアカウントにのみ影響
• 管理アカウントのみで、複数のアカウントの管理が可能
  • 一括請求

IAM アイデンティティセンター

• すべてのAWSアカウント、クラウドアプリケーションへのSSOアクセスを簡単に一元管理
  • ログインポータルのような感じで、各アカウントのマネージメントコンソールやCLIからアクセスが可能
• 複数のAWSアカウントに対して、SSOするためにOrganizationsとの連携が必要

AWS Control Tower

• 新しく安全なマルチアカウント、AWS 環境のセットアップとガバナンスに役立つ
  • 数回クリックするだけで、新しいAWS アカウントをプロビジョニング可能にする
  • どのAWSアカウントでも、同じガバナンスを一元管理できる
  • CloudFormationStackSetsを利用して、それぞれのアカウントで設定すべき設定を自動で展開してくれる

1. ランディングゾーン
2. コントール
   1. 予防（SCP）
   2. 検出（Config）
   3. プロアクティブ（CloudFormation）
3. Account Factory
   1. 設定可能なアカウントテンプレート
   2. アカウントのベースラインを焼き増し → AWS Service Catalog → 新しい AWS アカウント
4. ダッシュボード

モジュール３：ハイブリッド接続

AWS Client VPN

• AWS のリソースやオンプレミスネットワーク内のリソースへの安全なアクセスを可能にする、クライアントベースのマネージドVPN サービス
  • VPNエンドポイントと紐づけ

Site to Site VPN

• 仮想プライベートゲートウェイ、 AWS側の Transit Gateway と、オンプレミス側のカスタマーゲートウェイの間に2つのVPNトンネルを提供
  • ２つのエンドポイントに対して、オンプレミス側にある機器は２つとも同じカスタマーゲートウェイに接続しないといけない
• サイト間VPNを利用できない場合もある（インターネットを通じて通信をするため、それがNGだった場合使えない）
  • こういった要件の場合、Direct Connectを使う

Direct Connect

• AWSとの間に専用線をつなぐ
• オンプレミスのデータセンター → DXロケーション → VPC接続
• DXパートナーを利用して、専用線を引くことが出来る

• 物理的な専用線の中に、VIFと言われる仮想インターフェイスを作成する事も可能（パートナー接続という）
  • 占有型（物理的な回線を、パートナーから貸してもらう）
  • 共有型（仮想的な回線を、パートナーから貸してもらう）
  • ホスト接続（物理的な回線は不要だが、帯域保証が必要な場合に、帯域を指定して仮想的な回線をかしてもらう。上記二つのいいとこどり）

VIFの種類

1. パブリックVIF
   1. パブリックIPを使って、すべてのAWSのパブリックサービスにアクセス
2. プライベートVIF
   1. プライベートIPを使って、直接 or DirectConnect ゲートウェイ経由でVPCへアクセス
3. トランジットVIF
   1. DirectConnectゲートウェイ経由で、TransitGatewayにアクセス

Route53 Resolver

• プライベートホストゾーンを共有して Amazon Route 53 Resolver を使用
  • 共有 VPC エンドポイント の名前解決を一元化

モジュール５：ネットワークを接続する

FAQ

• VPCピアリング接続
  • ピアリング接続は、VPC間の１対１の関係
  • 異なるアカウントのVPCを接続できる

Transit Gateway

• VPC ⇔ オンプレを相互接続するために使用できるネットワークトランジットハブ
  • Transit Gatewayはリージョンのサービス
  • 別のリージョンのVPCとの接続には、Transit Gatewayピアリング接続が必要
• ２つのルートテーブル
  • VPCが持っているルートテーブル
  • Transit Gatewayが持っているルートテーブル

Cloud WAN

• 全てのリージョンをまたいで、一元的にネットワークをまとめることができる
• Transit Gatewayピアリング接続を沢山する場合、こちらを利用する選択肢もある

AWS Resource Access Manager

• アカウント全体または AWS Organizations の組織全体で Transit Gateway を共有して VPC をアタッチできる

ラボ２：Transit Gatewayを設定する

1. Transit Gateway を設定
2. VPC を Transit Gateway にアタッチ
3. AWS Transit Gateway でルーティングを制御およびカスタマイズ
4. 2 つのリージョン間で Transit Gateway をピアリング
5. Network Manager を使用してネットワークを可視化および分析

２日目

モジュール６：コンテナ

コンテナと仮想マシン

1. 仮想マシンは分離され、同じOSやバイナリ、ライブラリを共有することはない
2. コンテナは分離されるが、OSは共有され、バイナリやライブラリも必要に応じて共有される
   1. コンテナのストレージは、シャットダウンされると一緒に中身が削除される
   2. 外部のストレージを用意する必要がある（S3、DynamoDB、Auroraなど）

コンテナの種類

• イメージレジストリ（コンテナのイメージを保存しておく）
  • Amazon ECR
• ホスティング（コンテナが実行される場所）
  • Amazon EC2
  • AWS Fargate
• 管理（アプリケーションのデプロイ、スケジューリング、スケーリング）
  • Amazon ECS（これから新しくコンテナを使う場合は、AWSが用意しているこちらを選択）
  • Amazon EKS（kubernetesを使いたい場合はこちらを選択）

ラボ３：AWS FargateとAmazon ECSを使ってアプリケーションをデプロイする

1. コンテナイメージを Amazon ECR リポジトリにアップロードして、Amazon ECS のデプロイに使用
2. コンテナをリポジトリから Amazon ECS Fargate クラスターにデプロイ
3. Amazon ECS のサービスとタスクを作成
4. Amazon ECS Fargate クラスターの Docker コンテナでウェブベースのアプリケーションをテストおよびデモ

モジュール１3：エッジのためのアーキテクチャ設計

Amazon CloudFront

• エッジロケーションと呼ばれるデータセンターの世界的ネットワークを使用してコンテンツを配信
  • エッジキャッシュを利用すれば、ネットワーク経路を大幅に短縮できる

速さの比較

1. S3（サンパウロリージョン直接）約19秒
   1. https://adv-arch-demo.s3.sa-east-1.amazonaws.com/images/heic1901a.jp
2. TTL = 0（CloudFrontキャッシュなし）約２秒
   1. https://drad9ej5xdpo7.cloudfront.net/heic1901a.jpg
3. TTL > 0（CloudFrontキャッシュあり）１秒以下
   1. https://d289w59ygoazfl.cloudfront.net/heic1901a.jpg

ビヘイビア

• TTLを仮に30日間・１年間と設定しても、必ずしもエッジロケーションにコンテンツのキャッシュが残っているとは限らない
  • この場合もう一度オリジンに対して、リクエストが行われるような仕組みがとられる

Lambda@Edge

• Lamdbaの拡張機能
  • Lambdaと必ずしも、同じ機能が使えるわけではない。Node.jsとPythonのみなど制限がある
• ユースケース
  • ヘッダーの正規化
  • A/Bテスト

Global Accelerator

• エンドユーザーからのリクエストが、エンドユーザーの近くのエッジロケーションを経由して、ネットワーク経路を大幅に短縮できる
• 全てのクライアントは、同じ静的IPを差し、最も近いエッジロケーションに繋がる（これがCloudFrontとの違い）
  • CloudFrontの場合だと、DNSの仕組みが必ず使用
• キャッシュの機能はなし

速さの比較

モジュール８：高可用性とDDoS

FAQ

• アーキテクチャに対する冤罪的な脅威は？
  • サービス妨害
  • 悪意のあるボット
  • アプリケーションの脆弱性
  • 設定エラー

AWS WAF

• 分散環境でのDDoS防御
• 一般的なDDoS攻撃は、レイヤー３，４，６，７で起こる
  • レイヤー３，４に対しては、Shield Standard
  • アプリケーション（レイヤー７）に対しては、WAF
• ウェブACLでアクセス許可、または拒否するように設定
• フルログが取得できる
  • コンプライアンスと監査
  • Kibanaなどツールを使用してダッシュボードの構築

AWS Shield Advanced

• 月額3000ドル、一年間継続利用が必要
• マネージド型のDDoS対策
  • 24時間専門家からのShieldResponse Teamに相談が可能
  • ただし実際の実装は自分たちで行う必要がある
  • スケーリングに関するコスト保護

Firewall Manager

• WAF、Shield Advanced、VPC セキュリティグループを複数のアカウントとリソースにわたって管理およびメンテナンスする際のタスクを簡素化するサービス
  • Organizationsとの統合で、管理の簡素化
  • WAFルールへのコンプライアンスを確保
  • 組織全体を一元的に可視化
• 単体利用だと100ドル／ポリシー／リージョン
  • Sield Advancedを利用し、それと一緒に利用する方が安上がりになるケースもある

３日目

モジュール９：データの保護

暗号化：タイミング、場所

以下の３つの状態で、データ保護を考える必要がある

1. 移動中のデータ
2. 保管中のデータ
3. 使用中のデータ

暗号化：対象、方法、理由

• HSM（安くても１台50万、いいものだと3000万）
  • エンベロープ暗号化
  • 暗号化キーの生成

AWS KMS

• データの暗号化に使用される AWS KMS キーの作成と管理を容易にするマネージドサービス
  • 鍵の管理をKMSに任せる

CloudHSM

• FIPS140-2 レベル３に準拠（ただこの要件だけなら、KMSでも利用可能）
• シングルテナント

モジュール１０：大規模データストア

FAQ

• 一元化されていないデータストアを使用すると、どうな問題が発生するか？
  • データの冗長性が確認できない
  • セキュリティホール
  • データ破損
  • ユーザーの混乱

S3のデータ管理機能

• ストレージクラス分析
  •  ストレージクラスを適切に使う必要がある
  • 適切に使っているのか確認
• Intelligent-Tiering ソリューション
  • 自動的にアクセスパターンの変化に合わせて、データのストレージコストを自動的に最小限に抑えることができる
  • S3インベントリソリューション
    • 分析と監査のために、オブジェクトのリストを定期的に生成
• S3バッチオペレーション
  • S3に一括操作を行いたいときに利用
• インベントリ
• Access Points
  • 大規模なデータアクセスの管理を簡素化
  • ポリシーの管理性を高める
  • S3 Object Lambda
    • 画像データに対してアクセス制御を行い、有料じゃないと透かしのテキストを入れたりといったことが出来る

データレイク

• データレイクとデータウェアハウスの比較
  • データレイクにとりあえず、データを保存しておくといった要件のほうがやりやすい

1.  データレイク
   1. スキーマ定義されていない
   2. 構造化データ以外のデータも扱う
   3. ツールの柔軟性
   4. 精度レベルの低いデータ
2. データウェアハウス
   1. 事前定義されたスキーマ
   2. 構造化データのみ
   3. SQL互換のみ
   4. 概要、集約された詳細レベルのデータ

AWSでのデータレイク

• Kinesis Data Firehose
• AWS Glue（データをクロール・カタログ化）
• Amazon Athena（データをクエリ・分析）

Lake Formation

• BluePrintからある程度、テンプレート使って簡単にデータレイクを構築できる
• 一から構築するより、構築の時間を短縮できる

ラボ４：Lake Formationを使ってデータレイクを設定する

1. データレイクとデータベースを作成
2. AWS Glue を使用してデータをクロールしてメタデータとテーブルを作成
3. Athena を使用してデータをクエリ
4. Lake Formation でユーザー権限を管理

モジュール４：専用インフラストラクチャ

AWS Storage Gateway

• オンプレミスのデータを、低レイテンシーなアクセスでAWSに永続的に保存

VMware Cloud on AWS

• オンプレのVMware環境の災害対策
• オンプレ環境のデータセンターの拡張
• 次世代アプリケーション
  • オンプレとAWSの間を、VPNやDirectConnectでつなぐ

AWS Outposts

• AWSのサービスを、オンプレミスで動かしたいときに利用
• Outpostsラックをオンプレミス環境に接続し、AWSのサービスを利用
  • 使えるAWSサービスは限られている
• ラック使用料の月額料金を継続して、3年間支払う必要がある

Local Zones

• マネージメントコンソールで追加すると、追加のAZと同じように利用することが可能
  • 使えるサービスは、各ローカルゾーンごとに決まっていて限られている
• 特定のリージョンに紐づいたAZが、追加される

AWS Wavelength

• 最小限のネットワークホップで、5G ネットワーク 上のデバイスから AWS クラウド内のアプリケーションリソースにアクセス可能にする
• 日本の場合は、KDDIと提携して提供されている

モジュール１１：ワークロードの移行

移行の目標をたてる

• コスト削減
• スタッフの生産性
• 運用上の耐障害性
• ビジネスの俊敏性

移行における７つのR

1. リファクタリング
2. リプラットフォーム
3. 再購入
4. リホスト
5. 再配置
6. 保持（移行しない）
7. 使用停止（移行しない）

移行ツールのあれこれと事例

• Application Discovery Service
  • Control Towerを利用して、ベストプラクティスに沿ってアカウントの作成からマネージドサービスを利用して移行を行う
  • 収集した情報をMigration Hubで、現状どういった移行のステータスか確認ができる
• VMware Cloud on AWS
  • オンプレのサーバーを、そのままVPCにまるっと移行
• Application Migration Service
• DataSync
  • オンプレのデータをDatasyncを介して同期して、AWSとデータを双方向で同期
• Snowball

データベースの移行

• AWSのツールを必ずしも、使う必要はない
  • GoldenGateを使用してOracleデータベースを移行
• SCTソリューション
  • スキーマをAWSのネイティブサービスに変換してくれる
  • 完全に全てを変換できるわけではないので、人の手で手動変換をする必要がある

ラボ５：AWS DataSyncとStorage Gatewayを使用してオンプレミスの NFS 共有を移行する

1. DataSync エージェントを Amazon Elastic Compute Cloud (Amazon EC2) インスタンスとしてデプロイし、アクティブ化
2. DataSync タスクを作成し、データを Linux ベースの NFS サーバーから S3 バケットにコピー
3. Storage Gateway のファイルゲートウェイアプライアンスを EC2 インスタンスとしてデプロイ
4. ファイルゲートウェイで NFS ファイル共有を作成
5. ファイルゲートウェイで NFS 共有に接続するように Linux ホストを設定

おわりに

全体的に、今回のトレーニングは今の自分の知識レベルでは、難しい内容が多かったため、一回説明を聞いただけでは理解が追い付きませんでした。

SAAを取得後に、受講しても良いのですが、8割程度は内容を一度で理解したいとなった場合、私の感覚だと以下の専門コースを受講し、さらにそれに付随する資格も取得後に受講したほうが、理解度が深まりラボの進み具合も捗りそうと感じました。

各セキュリティサービスの特徴が理解できる【Security Engineering on AWS】を受講してみた

AWSの各DBの特徴が把握できる【Planning and Designing Databases on AWS】を受講してみた

この記事がどなたかのお役に立てば幸いです。